NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/6753

Text File | 1996-08-05 | 5.9 KB | 124 lines

Newsgroups: comp.lang.c++
Path: netcom.com!milyng
From: [e-mail] (Jerry Garcia)
Subject: Re: Linking LIBs (file dependencies)
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Ghost Communications, Inc.
X-Newsreader: WinVN 0.99.7
References: <4ee2ta$[e-mail]> <[e-mail]> <4f3fnq$[e-mail]>
Date: Mon, 12 Feb 1996 06:29:21 GMT

In article <4f3fnq$[e-mail]>, [e-mail] says...

>Thanks.  That problem dissapeared (and I didn't even do anything!).

I wish all problems were that simple :)

>I have a new problem now, but I think I found a solution.  My program (a
>dragon game) runs fine, but crashes randomly when the program exits.  I
>run it, it crashes, I reset the computer, I run it again, and it works
>fine!  I tried doing a COMPILE/BUILD ALL before running and it hasn't
>crashed for a while.  Does that option have anything to do with module
>structurization?

Hmm...  It sounds like your problem is that things get out of sync - that
not all required files are rebuilt properly when you make a change somewhere.

If that's the case, which it commonly is when you experience spurious errors
that disappear after a complete rebuild, you need to do one of the following:
1) Use the brute force method - always do a complete rebuild.  2) Ensure your
source file dependencies are correct.  I.e., somewhere, somehow you specify
the dependencies between modules in your IDE (I assume you're using an IDE
because of your reference to COMPILE/BUILD ALL) and somehow these dependencies
aren't up to date.  How to manage dependencies depends (pun intended)
extremely much on exactly how you build your application.  If you're using a
make utility, you pretty much have to keep them up to date yourself.  If
you're using MSVC, I think it does most (if not all) of the work for you.  As
for Borland (that's the one you're using?  I don't recall COMPILE/BUILD ALL in
any other IDE), I think you have to do it manually in the IDE somehow.  I will
here describe what you need to do get your dependencies up to date manually -
this method works for both makefiles and for Borland's IDE.

In make/build terms, file A depends upon file B if file A needs to be
recompiled/remade/rebuilt/regenerated/whatever whenever file B is changed.
The most obvious type of dependency is that the dependency between an object
file and the source file used to generate the object file.  In virtually all
cases where the source file has been changed, the object file needs to be
rebuilt (by compiling the source file).  In a makefile this is typically
expressed as:

    filename.obj: filename.c

However, this is the most simple type of dependency.  I guess you can call it
a "source dependency".  The one that causes most problems are "usage
dependencies" - where one file uses another without causing a new file to be
created.  A good example of this is a C source file's use of a header file.
If the header file changes, the object file created from the C source file
should be updated - even though the C source file hasn't been changed.  In a
makefile, this can be expressed in two ways:

    filename.obj: filename.c header.h

Or more correctly:

    filename.obj: filename.c

    filename.c  : header.h

(I consider this "more correct' because it means "filename.obj depends upon
filename.c.  filename.c depends upon header.h" (vs. "filename.obj depends upon
filename.c and header.h").

Anyway, from here on things are pretty simple.  Just as a C source file can
depend upon a header file (by including it), a header file can also depend
upon another header file (by including it).  And so forth - a library depends
upon the object files in the library who again depends upon the source files
used to create them who again depends upon the header files they include.

So, you pretty much just need to go through all of your source files and
determine what header files they depend upon.  After that, you go through all
your header files and determine what header files they depend upon.  When you
have all this information, you can pass it on to your build tool - whether a
make utility or an IDE of some sort.

A few notes:

1. Outdated dependency information is usually worth less than no dependency
information (because outdated dependency information frequently causes
programs to be built on outdated assumptions, whereas no dependency
information usually requires the program to be completely rebuilt - which is
tedious, but gives the proper result).

2. When you "map" dependency information, you rarely need to include
"standard" headers (such as the ANSI C library headers and 3rd party library
headers).  These headers change so infrequently that it doesn't seem very
useful to keep checking if they have changed.  You just need to remember to do
a complete rebuild whenever you update your compiler etc (which shouldn't be
that hard).  A good way to distinguish between standard, or global, headers
and project-specific, or local, headers, is to use the #include statement
itself to distinguish:

#include <global.h>    /* angle braces indicate global header */

#include "local.h"     /* quotes indicate local header */

As a matter of fact, most dependency mapping tools support this directly.
They won't include information about header files listed in angle braces (and
won't scan them for dependencies either), but will include the headers listed
in quotes.

3. Consider to use a make-like notation (as in the example above).  If you
keep doing this, you will someday find yourself wanting to use a real make
utility (and be able to do it easily).  The primary advantage of this, is that
you free yourself of vendor-dependencies and will make life much easier for
yourself, if you someday decide to switch to another compiler or you need to
port your app to another platform.

Hope this is of some help to you.  Sorry if it is wildly off track, but I kind
of got caught up in explaining this :)


Mikael